Events - 1.42.0

Bookable Areas, Assign a Guest to a Table - PPL-458

This feature will enable configuration of the Bookable Areas journey.

For a full guide on configuration of Bookable Areas, including Capacity Management, and how to enable Bookable Areas within your Estate, please see this document.

NOTE: Third party integrators using the Events API will not working when the Bookable Areas feature is enabled against an outlet.

Once configured and enabled, Bookable Areas will impact the following four booking journeys:

• Tables Host app

• Events Host app

• Events Widget

• (External) Events API

When Bookable Areas is disabled for an outlet, there will be no change to the booking journey in either host apps, widget, or via the API.

General changes

When the Bookable Areas feature is enabled, the following changes will apply to each of the four impacted booking journeys.

• Area selection will now be mandatory when creating a booking.

• Upon completing the booking process, the booking will be assigned to a table within the selected area, and capacity reduced from that area accordingly, without impacting the capacity of other areas.

• Upon creation, the booking will be locked to the selected table within the chosen area.

  • Bookings created from an enquiry will have the area saved against them, but will not be automatically assigned a table. This will require manually assigning a table.

Host Apps (Tables Host and Events Host)

When the Bookable Areas feature is enabled, the Booking creation journey is changing to include the following:

• In Tables Host, the Occasion selection step will now come immediately after guest selection, and before timeslot selection, but otherwise remains unchanged.

  • This is so at the point of timeslot-area selection, we can display the areas linked to the occasion.

  • This will now match the Events Host app booking journey.

• Area selection has been merged with timeslot selection to allow for area capacity to be viewed alongside timeslot selection.

• In the event of an overbooking, the area will continue to be stored against the booking to be manually assigned to the correct area at a later time.

• Once a session has been selected (if applicable), but prior to timeslot or area selection, specific capacity information has been removed, with only general capacity information provided. Areas linked to the previously selected occasion will remain shown via the link icon.

  • In the Tables Host app:

    

  • In the Events Host app:

    

• Once an area has been selected, capacity information will now be shown for that specific area only.

  • In the Tables Host app:

    

  • In the Events Host app:

    

• In the Tables Host app, when a timeslot has been selected, it will appear green:

  • 

The rest of the booking journey remains unchanged except where noted above.

Events Widget

• Only timeslots which have capacity (based on guest selection) within an area will be visible to the guest.

• If there is no capacity in any timeslot in any area, then the guest will not be able to proceed through timeslot selection unless enquiry is enabled (as per current functionality).

• If only one area is available for guest selection, then this area will be pre-selected for the guest.

• If multiple areas are available for selection, the guest will not be able to proceed with the booking journey until an area has been selected, as area selection is mandatory where Bookable Areas in enabled.

There are no further changes to the Events Widget.

Events External API

• A new endpoint created called /SlotAreas, that now returns the available areaID against a timeslot.

  • This endpoint will only work when the Bookable Areas feature is enabled.

• Area selection is now mandatory when creating a booking.

• The full LiveRES Events API spec version 1.86.0 can be found here.

 

Tables changes to accommodate for Events Capacity Groups + Bookable Areas - PPL-656

195261 - Update warning message in Tables Admin

As Capacity Groups are exclusive to Events, Tables does not have the ability to manage timeslots across Capacity Groups. A limitation of this is, if multiple capacity groups exist in Events, and the Tables Admin timeslot creation tool is used for a Standard Day, the Events timeslots in all Capacity Groups for the same matching day (eg Monday) will be deleted.

The warning text on Tables Admin timeslot creation has been updated to reflect this.

150783 - Lock/Unlock slots across Capacity Groups in Tables

The ability to lock and unlock slots will now be possible across different bookable areas/capacity groups. Upon selecting the 'Lock/Unlock' button in Tables Host, the timeslots pop-up will now feature buttons for each configured area, where those timeslots can now be managed independently. The 'Save' button will save all tabs in the current form.

Amending timeslots capacity via this screen for a Standard Day will continue to create a Special Day, as per current functionality.

 

Migration of Booking Rules - PPL-716

Booking Rules - Enable feature

After this release you will be able to configure booking rules to allow particular requirements to be applied to a booking when specific conditions are met. The first phase of this feature is primarily extracting the conditions and booking requirements that currently can be configured on a menu and moving them into Booking Rules. This can be accessed from the new 'Booking Rules' tab within Events Admin

The initial available conditions that can be set against a booking rules are:

• The occasion

• The menu

• The number of covers on a booking

The requirements that can be applied when the conditions are met are:

• Require a deposit

• Require a pre-order

• Require a pre-payment

• Require a pre-authorisation

For a full explanation of the new Booking Rules functionality, please see the eLearning Document 'Booking Rules'.

 

Booking Rules - API Changes

With booking rules introduced, booking requirements can now originate not only from a selected menu, but also from additional conditions, like an occasion or the number o covers. Therfore, it would be inappropriate to return deposit and other requirement details in a Menu schema. To support booking rules, we have introduced changes t External API shown in the below summary:

1. A new Requirements endpoint is added to request booking requirements during a booking journey (please see liveRes Events API spec 1.8.6 > Detail requirements endpoint)

2. A returned response will contain deposit, pre-authorisation, pre-order and pre-payment details (please see liveRes Events API spec 1.8.6 > Schemas > Requirements).

3. The following properties are deprecated from a Menu schema (please see liveRes Events API spec 1.8.6.1 > Schemas > Menu):

   • depositPerAdult

   • depositPerChild

   • preAuthAlwaysRequired

   • preAuthMinCovers

4. The following property is deprecated from an Event schema (please see liveRes Events API spec 1.8.6 > Schemas > Event):

   • preAuthRequired

5. The existing Event schema has been extended with requirements property to return booking requirements applied to a booking (please see liveRes Events API spec 1.8.6 > Schemas > Event).

 

For more technical details please refer to liveRes Events API Spec 1.8.6, while more detailed business explanation can be found in the eLearning document ‘Booking Rules’.

 

Import tool to respect booking rules

When Reservations bookings are imported to Events by an Estate Admin, an attempt will be made to match the bookings to Events booking rules. If matched, a booking will be imported with the booking requirements originating from a matched booking rule, not from a selected menu.

 

Migration between existing menus and simplified booking rules

Once booking rules are deployed and the new configuration page becomes available, you’ll see that we have migrated all existing requirements that have already been configured against a menu and converted them to booking rules. You will be able to see those in the booking rules summary pages.

Moreover, the requirements configuration from the menu pages has been removed, and Pre-order tab has been re-arranged to look as follows:

You will not lose configuration of the old menu rules, and the output will still be the same – thanks to migration, new bookings will have the same requirements applied as they would if the menu configuration still existed.

For more technical details please refer to liveRes Events API Spec 1.8.6, while more detailed business explanation can be found in the eLearning document ‘Booking Rules’.

 

Booking Rules - Feature Modifications to support migration - PPL-772

To make sure menu-based requirements can be successfully migrated to booking rules, we introduced a few minor changes to the booking rule configuration page. Those are:

• Deposit, pre-order, pre-payment and pre-authorisation descriptions are no longer required to save a booking rule;

• Pre-order and pre-payment due dates can be set to 0;

• Due dates for all requirements can be set either in days or in hours.

Widget - update how deposit is displayed in Estimated Costs

Since a deposit can now be triggered not only by a menu selection, but also by an occasion selection or the number of covers booked, we changed the way the deposit is displayed on the Booking Confirmation page in the Online Widget.

 

Early development has begun on the below features, planned for later releases.

Aha ID	Feature Summary
PPL-675	Set a default occasion in Events.
PPL-729	Add Enquiry Management to Events and the Events External API
PPL-554	Supply iOrder menu ID in the Events External API

 

 

Zonal ID	Description - Events Admin
17038	Booking Rules - Import Tool, part 2
17048	Migration of menus to booking rules
150782	Occasion-Area link tooltip
150784	Prevent capacity management access when not Tables integrated
175008	Booking Rules - make description fields optional
175041	Booking Rules - allow 'Due before Arrival' to be 0
175042	Booking Rules -'Due before arrival' in hours
195258	Prevent Bookable Areas toggle where not Tables integrated
289616	Booking Rules - Add Occasion as a condition

 

Zonal ID	Description - Events Host
175042	Booking Rules -'Due before arrival' in hours
195250	Events Host Area Selection
209287	Booking rules - Events Host and Widget Menu UI cleanup

 

Zonal ID	Description - External API
86056	Booking Rules - update External API
175042	Booking Rules -'Due before arrival' in hours
195229	External API Area selection

 

Zonal ID	Description - Events Admin
175008	Booking Rules - make description fields optional
175042	Booking Rules -'Due before arrival' in hours
194280	Booking rules - Widget - update how deposit is displayed in Estimated Costs
194383	Widget Area Selection
209287	Booking rules - Events Host and Widget Menu UI cleanup

 

Zonal ID	Description - Events Admin
255917	Cannot edit bookings after their occasion is removed from the site
233169	Menu with child only deposit - Error on guest portal (Payment still goes through)